home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-dns-idpr-01.txt < prev    next >
Text File  |  1993-09-20  |  7KB  |  224 lines
  1.  
  2.  
  3. Network Working Group                                         R. Austein
  4. INTERNET-DRAFT                           Epilogue Technology Corporation
  5.                                                           September 1993
  6.  
  7.  
  8.                           DNS Support for IDPR
  9.                       [draft-ietf-dns-idpr-01.txt]
  10.  
  11.  
  12. Status of this Memo
  13.  
  14.    This document is an Internet Draft.  Internet Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its Areas,
  16.    and its Working Groups.  Note that other groups may also distribute
  17.    working documents as Internet Drafts.
  18.  
  19.    Internet Drafts are draft documents valid for a maximum of six
  20.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  21.    other documents at any time.  It is not appropriate to use Internet
  22.    Drafts as reference material or to cite them other than as a "working
  23.    draft" or "work in progress."  Please check the 1id-abstracts.txt
  24.    listing contained in the internet-drafts Shadow Directories on
  25.    nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or
  26.    munnari.oz.au to learn the current status of any Internet Draft.
  27.  
  28.    This is a working document only, it should neither be cited nor
  29.    quoted in any formal document.
  30.  
  31.    This document will expire before 25 March 1994.
  32.  
  33.    Distribution of this document is unlimited.
  34.  
  35.    Please send comments to the author.
  36.  
  37. 1. Introduction
  38.  
  39.    This note documents the support needed from the Domain Name System
  40.    (DNS) by Inter-Domain Policy Routing (IDPR).  The DNS changes are
  41.    minor and can be deployed with minimal impact on the installed DNS
  42.    community.
  43.  
  44.    When an IDPR Policy Gateway receives an IP packet, it needs to map
  45.    the packet's IP address to an IDPR Administrative Domain (AD) in
  46.    order to deliver the packet.  The initial prototype implementation of
  47.    IDPR used a configuration file to provide this mapping, but this is
  48.    clearly unacceptable for a full-scale deployment of IDPR.  As an
  49.    existing, well understood, (relatively) low-overhead distributed
  50.    database, the DNS is the obvious mechanism by which to distribute
  51.  
  52.  
  53.  
  54. Austein                  Expires 25 March 1994                  [Page 1]
  55.  
  56. INTERNET-DRAFT            DNS Support for IDPR            September 1993
  57.  
  58.  
  59.    these mappings.
  60.  
  61.    Due to an unfortunate collision in use of the term "domain" by both
  62.    IDPR and the DNS, this note avoids unqualified use of the term
  63.    "domain."
  64.  
  65. 2. The AD RR type.
  66.  
  67.    We define one new DNS RR type, with symbolic name "AD" and numeric
  68.    value xxx.  This RR type is class-independent; the rest of this note
  69.    discusses IN class AD RRs, with the understanding that the mechanism
  70.    described here is not tied to IP addresses.  The RDATA portion of an
  71.    AD RR consists of two 32-bit integers, each representing an IDPR AD.
  72.    The two fields are the "home" AD associated with the address, and the
  73.    proxy AD associated with the address.  An AD which is acting as its
  74.    own proxy (the normal case) has the same value for these two fields.
  75.  
  76.    Class IN AD RRs appear in the IN-ADDR.ARPA portion of the DNS name
  77.    space.  These RRs are used to map from an IP address to an IDPR AD.
  78.    We expect that it will be possible to make heavy use of "wildcard"
  79.    DNS names here, since we expect that all the hosts on a given IP
  80.    network (or subnetwork) are likely to belong to a single IDPR AD.
  81.  
  82.    For purposes of discussion, assume that Miskatonic University is in
  83.    Administrative Domain 42, while Engulf & Devour, Inc., is in
  84.    Administrative Domains 666 and 17; Engulf & Devour recently purchased
  85.    Liver Donors Ltd., in order to use their Policy Gateway as a proxy
  86.    for Engulf & Devour's corporate network.  The following RRs might
  87.    appear in the DNS:
  88.  
  89.            Loki.Miskatonic.EDU.   IN A 1.1.1.5
  90.            Thor.Miskatonic.EDU.   IN A 1.1.1.6
  91.            Liver-Donors.EaD.COM.  IN A 2.2.2.7
  92.            HQ.EaD.COM.            IN A 3.3.3.8
  93.  
  94.            5.1.1.1.IN-ADDR.ARPA.  IN PTR   Loki.Miskatonic.EDU.
  95.            5.1.1.1.IN-ADDR.ARPA.  IN AD    42  42
  96.            6.1.1.1.IN-ADDR.ARPA.  IN PTR   Thor.Miskatonic.EDU.
  97.            6.1.1.1.IN-ADDR.ARPA.  IN AD    42  42
  98.            7.2.2.2.IN-ADDR.ARPA.  IN PTR   Liver-Donors.EaD.COM.
  99.            7.2.2.2.IN-ADDR.ARPA.  IN AD    666 666
  100.            8.3.3.3.IN-ADDR.ARPA.  IN PTR   HQ.EaD.COM.
  101.            8.3.3.3.IN-ADDR.ARPA.  IN AD    17  666
  102.  
  103.    In this case the AD RRs for Miskatonic University could usefully be
  104.    collapsed into a wildcard RR:
  105.  
  106.            *.1.1.1.IN-ADDR.ARPA.  IN AD    42  42
  107.  
  108.  
  109.  
  110. Austein                  Expires 25 March 1994                  [Page 2]
  111.  
  112. INTERNET-DRAFT            DNS Support for IDPR            September 1993
  113.  
  114.  
  115. 3. Use of the AD RR type.
  116.  
  117.    In the initial deployment of of IDPR, we believe that only IDPR
  118.    Policy Gateways will need to know about IDPR ADs.  Thus, only Policy
  119.    Gateways will need to obtain and use AD RRs.  In the long run it may
  120.    be beneficial for hosts to obtain this data as well, but it is not
  121.    necessary that they do so in order for IDPR to work correctly.
  122.  
  123. 4. Bootstrapping the Policy Gateways
  124.  
  125.    Since a Policy Gateway needs an AD before it can forward a packet,
  126.    the AD associated with the IP addresses of each of the Policy
  127.    Gateway's default DNS name servers needs to be part of the Policy
  128.    Gateway's configuration.  Ie, there is a bootstrapping problem here,
  129.    because we can't use the DNS to obtain the ADs we need in order to
  130.    talk to the DNS.  Note that the Policy Gateway's default DNS name
  131.    servers are not necessarily the root DNS name servers; indeed, clever
  132.    use of centralized DNS caches by a community of Policy Gateways will
  133.    help decrease the load IDPR will add to the existing DNS system.
  134.    Ultimately, however, this question reduces to the question of how the
  135.    Policy Gateways reach the DNS root servers.
  136.  
  137. 5. Glue RRs
  138.  
  139.    Since in some cases the authoritative nameservers for a particular AD
  140.    RR may be within the AD itself, it may be necessary to insert "glue"
  141.    AD RRs into some zones in the IN-ADDR.ARPA tree.  These fill the same
  142.    role as the glue A RRs already in use to solve the analogous problem
  143.    with finding the IP address of a name server.
  144.  
  145. 6. Security Considerations
  146.  
  147.    Security considerations ane not discussed in this memo.
  148.  
  149. 7. Acknowledgments
  150.  
  151.    Most of the ideas in this document were derived from email
  152.    conversations with Martha Steenstrup and Robert Woodburn, without
  153.    whose help the author would still be completely clueless about IDPR
  154.    and its requirements.
  155.  
  156. 8. References
  157.  
  158.    [1]  Steenstrup, M., "An Architecture for Inter-Domain Policy
  159.         Routing", RFC 1478, June 1993.
  160.  
  161.    [2]  Mockapetris, P., "Domain names - concepts and facilities", RFC
  162.         1034, November 1987.
  163.  
  164.  
  165.  
  166. Austein                  Expires 25 March 1994                  [Page 3]
  167.  
  168. INTERNET-DRAFT            DNS Support for IDPR            September 1993
  169.  
  170.  
  171.    [3]  Mockapetris, P., "Domain names - implementation and
  172.         specification", RFC 1035, November 1987.
  173.  
  174.    [4]  Lottor, M., "Domain administrators operations guide", RFC 1033,
  175.         November 1987.
  176.  
  177. 9. Author's address:
  178.  
  179.       Rob Austein
  180.       Epilogue Technology Corporation
  181.       268 Main Street, Suite 283
  182.       North Reading, MA 01864
  183.       USA
  184.  
  185.       Phone: +1-617-942-0915
  186.       EMail: sra@epilogue.com
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222. Austein                  Expires 25 March 1994                  [Page 4]
  223.  
  224.